home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-houttuin-mailservers-00.txt < prev    next >
Encoding:
Text File  |  1993-03-03  |  26.7 KB  |  873 lines
  1.  
  2.  
  3.  Mail Requirements Group                      Jeroen Houttuin
  4.  INTERNET-DRAFT                                Allan Cargille
  5.                                                September 1992
  6.     
  7.     
  8.     
  9.     
  10.     
  11.                               
  12.                               
  13.              Requirements for mail based servers
  14.  
  15.  
  16.     
  17.  Abstract 
  18.     
  19.     This document defines minimal requirements and
  20.     recommendations that must be implemented in all mail based
  21.     servers in the Internet e-mail community and all e-mail
  22.     networks connected to it, such as the GO-MHS community.
  23.     
  24.  
  25.  Status of this Memo
  26.     
  27.     This document is an Internet Draft. Internet Drafts are
  28.     working documents of the Internet Engineering Task Force
  29.     (IETF), its Areas, and its Working Groups. Note that other
  30.     groups may also distribute working documents as Internet
  31.     Drafts.
  32.     
  33.     Internet Drafts are draft documents valid for a maximum of
  34.     six months. Internet Drafts may be updated, replaced, or
  35.     obsoleted by other documents at any time.  It is not
  36.     appropriate to use Internet Drafts as reference material
  37.     or to cite them other than as a "working draft" or "work
  38.     in progress."
  39.     
  40.     Please check the I-D abstract listing contained in each
  41.     Internet Draft directory to learn the current status of
  42.     this or any other Internet Draft.
  43.     
  44.     Distribution of this memo is unlimited.
  45.  
  46.  
  47. INTERNET-DRAFT                                         September 1992
  48.  
  49.  
  50.  Contents
  51.  
  52.     1. Introduction                                      1
  53.     2. Terminology                                       3
  54.     3. Mail based server types                           4
  55.       3.1. Replier                                       5
  56.            3.1.1. Echo server                            5
  57.            3.1.2. (NON)-Delivery Message                 5
  58.            3.1.3. Command server                         5
  59.            3.1.4. Auto-replier                           5
  60.       3.2. Forwarder                                     6
  61.            3.2.1. Distribution List                      6
  62.            3.2.2. Auto-forwarder                         6
  63.     4. Requirements                                      6
  64.       4.1. General                                       7
  65.       4.2. Repliers                                      7
  66.            4.2.1. Echo-servers                           8
  67.            4.2.2. (NON)-Delivery Messages                9
  68.            4.2.3. Command servers                        9
  69.       4.3. Forwarders                                   10
  70.            4.3.1. Distribution Lists                    10
  71.            4.3.2. Auto-forwarders                       10
  72.     5. Recommendations                                  10
  73.       5.1. General                                      10
  74.       5.2. Repliers                                     11
  75.            5.2.1. Echo-servers                          11
  76.            5.2.2. Command servers                       11
  77.       5.3. Forwarders                                   12
  78.            5.3.1. Distribution Lists                    12
  79.            5.3.2. Auto-forwarders                       12
  80.     6. Mapping to X.400(88) and RFC 822                 12
  81.     7. Acknowledgements                                 13
  82.     8. References                                       13
  83.     9. Authors' Addresses                               14
  84.  
  85.  
  86.  1. Introduction
  87.  
  88.     
  89.     Electronic mail systems are increasingly being used by
  90.     automated processes, such as echo servers, distribution
  91.     lists, etc. Although such applications differ widely in
  92.     nature, they have many properties and problem areas in
  93.     common and can be grouped under the term 'mail based
  94.     servers'.
  95.     
  96.     Mail based servers are used for a number of purposes:
  97.       
  98.       - Enhancing the Message Handling Environment. Examples
  99.         of such usage are distribution lists (DLs) and mail
  100.         based file servers.
  101.  
  102.  
  103.  
  104. Houttuin, Cargille     Expires: April 1993              [page  1]
  105.  
  106. INTERNET-DRAFT                                         September 1992
  107.  
  108.  
  109.       - Monitoring the status of the MHS. Examples of this
  110.         usage are echo servers and forced (non-)delivery
  111.         messages (the so-called nosuchuser test).
  112.    
  113.     Since mail based servers deal with automatically
  114.     receiving, forwarding and replying to messages, which may
  115.     themselves have been generated by automatic processes,
  116.     strong requirements are needed on the one hand to minimise
  117.     human effort to manage such servers, and on the other hand
  118.     to make the behaviour of mail based servers deterministic
  119.     enough to build reliable tools upon them.
  120.     
  121.     A classic example of what can go wrong is when a DL
  122.     contains an invalid address. The remote mailer generates a
  123.     non-delivery message and sends it to the originator of the
  124.     original message, which, under circumstances, could be the
  125.     DL itself, which then again distributes the non-delivery
  126.     message to the non-existing recipient, etc. Following
  127.     strict requirements on how a DL should handle message
  128.     header fields will avoid such looping-endangered
  129.     situations.
  130.     
  131.     A more complicated example of the usefulness of strong
  132.     requirements for mail based servers is the following:
  133.     suppose a distributed tool will check the connectivity of
  134.     mailers by sending a message to an echo-server. The
  135.     connectivity tool could request the echo to be sent to
  136.     another component of the tool instead of to itself. If for
  137.     some reason the address of that other component cannot be
  138.     routed to, an automatically generated non-delivery message
  139.     could be sent back to the echo server, which results in a
  140.     message loop.
  141.     
  142.     Throughout this document, X.400(84) terminology is
  143.     preferred to X.400(88) and RFC 822 for the following
  144.     reasons
  145.       
  146.       - X.400 has more pre-defined message attributes than
  147.         RFC 822
  148.       
  149.       - X.400(88) has already defined a specific mechanism
  150.         for DLs. This implies that a separate recommendation
  151.         for a mail based server approach to DLs is only
  152.         useful in the context of X.400(84) or RFC 822.
  153.       
  154.       - Requirements for mail based servers are needed now.
  155.         Since most available products are X.400(84)
  156.         implementations, this document will sort more effect
  157.         if it uses X.400(84) terminology.
  158.     
  159.     Once expressed in X.400(84) terminology, most requirements
  160.     can be mapped to RFC 822 and X.400(88) mail systems using
  161.     
  162.  
  163. Houttuin, Cargille     Expires: April 1993                [page  2]
  164.  
  165. INTERNET-DRAFT                                       September 1992
  166.  
  167.  
  168.     RFC 1327 and X.400(84) to X.400(88) upgrading,
  169.     respectively. For the reader's convenience, chapter 6
  170.     lists the used X.400(84) terminology together with their
  171.     RFC 822 and X.400(88) equivalents. For those requirements
  172.     that cannot be mapped implicitly, chapter 6 will also
  173.     explicitly state how such requirements must be implemented
  174.     for the other mail standards.
  175.     
  176.     The requirements defined in this document will as much as
  177.     possible be aligned with comparable rules that either have
  178.     already been defined in other standards (X.400(88) DLs) or
  179.     have already been used for a long time (X.400(84) Status
  180.     Reports; distribution lists in the Internet).
  181.  
  182.  
  183.  2. Terminology
  184.  
  185.  
  186.  
  187.  Mail based server (MBS)
  188.  
  189.     
  190.     A mail based server is a process in an MHS that
  191.     automatically generates (a) message(s) as a result of
  192.     receiving a message. An MBS can be implemented/modelled in
  193.     the following ways:
  194.       
  195.       - within the MTS, in which case it can be considered an
  196.         enhancement of the X.400 message dispatcher. This is
  197.         called a P1 MBS.
  198.       
  199.       - as an MTS service user, in which case it can be
  200.         considered an automated User Agent (UA). Per default,
  201.         this is called a P3 MBS. If, in addition, the MBS is
  202.         P2 based, it is called a P2 MBS.
  203.     
  204.     Upon receiving a message, an MBS will generate at least
  205.     one message, whose contents and list of recipients depend
  206.     on
  207.       
  208.       - the kind of server
  209.       
  210.       - the contents and header of the received message.
  211.  
  212.  
  213.  (Non-)Dedicated MBS
  214.  
  215.     
  216.     A dedicated MBS is an MBS that is meant to be used as an
  217.     MBS only. Examples of non-dedicated MBSs are auto-
  218.     forwarding UAs, and UAs that automatically send back
  219.     vacation notes (auto-repliers).
  220.  
  221.  
  222. Houttuin, Cargille     Expires: April 1993                [page  3]
  223.  
  224. INTERNET-DRAFT                                       September 1992
  225.  
  226.     
  227.  MBS administrator
  228.  
  229.     For every dedicated MBS, there exists an MBS administrator
  230.     who is responsible for managing the MBS.
  231.  
  232.  
  233.  MBS Submit Permission
  234.  
  235.     
  236.     Associated with an MBS is a list of addresses that are
  237.     allowed to use the MBS (I.e. have the MBS send output
  238.     messages). Implementation of MBS Submit Permission is
  239.     considered a local matter. The main implementation options
  240.     are:
  241.       
  242.       - Implicit: Only those addresses explicitly listed are
  243.         not allowed to send messages to the MBS.
  244.       
  245.       - Explicit: Only those addresses explicitly listed are
  246.         allowed to send messages to the MBS.
  247.  
  248.  
  249.  Messages
  250.  
  251.     
  252.     An input message is a message that triggers the generation
  253.     of (a) message(s) by an MBS. Depending on the
  254.     implementation of the MBS, this is defined either as a
  255.     P1.MPDU or as the parameters of an MTS.DELIVER.Indication.
  256.     
  257.     An output message is a message that is being generated by
  258.     an MBS as a result of a received input message. Depending
  259.     on the implementation of the MBS, this is defined either
  260.     as a P1.MPDU or as the parameters of an
  261.     MTS.SUBMIT.Request.
  262.  
  263.  
  264.  Originator
  265.  
  266.     
  267.     For P2 messages, the originator of an input message is
  268.     defined as the P2.originator, or if this attribute is not
  269.     present, the P2.authorizingUsers. For non-P2 messages, the
  270.     originator of an input message is defined as the
  271.     P1.originator.
  272.  
  273.  
  274.  3. Mail based server types
  275.  
  276.     
  277.     This chapter defines the different types of MBSs. Two main
  278.     types are identified: repliers and forwarders.
  279.  
  280.  
  281. Houttuin, Cargille     Expires: April 1993                [page  4]
  282.  
  283. INTERNET-DRAFT                                       September 1992
  284.  
  285.  
  286.  3.1. Replier
  287.  
  288.     
  289.     Intuitively speaking, a replier is an MBS that will send
  290.     an output message to the originator of the input message.
  291.     There are also exceptions to this rule, such as replying
  292.     to a P2.replyToUsers field. More formally speaking, a
  293.     replier is characterised by the fact that the recipient of
  294.     the output message is uniquely defined in (the heading of)
  295.     the input message. The different types of repliers can be
  296.     classified by the content of the output message.
  297.  
  298.  
  299.  3.1.1. Echo server
  300.  
  301.     
  302.     An echo server is a dedicated replier that will submit the
  303.     contents of the input message.
  304.  
  305.  
  306.  3.1.2. (NON)-Delivery Message
  307.  
  308.     
  309.     This document does not consider the behaviour of
  310.     P1.Service.MPDUs and P2.SR-UAPDUs, which is assumed to be
  311.     well defined in X.400(84) already.  RFC 822 mailers and
  312.     RFC 1327 gateways however can generate a message (P2.IM-
  313.     UAPDU) explaining the (NON-)Delivery of an input message.
  314.     In this case the mailer/gateway can be considered an MBS.
  315.     
  316.     The MBS administrator is the administrator of the
  317.     mailer/gateway.
  318.  
  319.  
  320.  3.1.3. Command server
  321.  
  322.     
  323.     The contents of an output message submitted by a command
  324.     server depends on commands that were included in the input
  325.     message. Concrete examples are file servers, archie
  326.     servers, DL-registration servers and address conversion
  327.     servers.
  328.  
  329.  
  330.  3.1.4. Auto-replier
  331.  
  332.     
  333.     Some UAs have an auto-reply feature that will temporarily
  334.     and/or conditionally turn the UA into an MBS. Thus an auto-
  335.     replier is a non-dedicated replier. The content of the
  336.     output message is often a note such as 'I am on holidays.'
  337.  
  338.  
  339.      
  340. Houttuin, Cargille     Expires: April 1993                [page  5]
  341.  
  342. INTERNET-DRAFT                                       September 1992
  343.  
  344.  
  345. 3.2. Forwarder
  346.  
  347.     
  348.     A forwarder is an MBS that will send its output messages
  349.     to a list of recipients. These recipients are independent
  350.     of (the heading of) the input message.
  351.  
  352.  
  353.  3.2.1. Distribution List
  354.  
  355.     
  356.     Upon receiving an input message, a DL will generate output
  357.     messages to a list of DL members, which is managed by the
  358.     MBS administrator.
  359.     
  360.     In X.400(84), no DLs are defined. Many vendor-specific
  361.     implementations exist, some of which are nothing more than
  362.     local multi-recipient aliases, others use local
  363.     directories for DL expansion. This document defines the
  364.     requirements for X.400(84) DLs as well as a recommendation
  365.     for how to implement them. Their behaviour will as much as
  366.     possible be aligned with that of X.400(88) DLs.
  367.  
  368.  
  369.  3.2.2. Auto-forwarder
  370.  
  371.     
  372.     Some UAs have an auto-forward feature that will
  373.     temporarily and/or conditionally turn the UA into an MBS.
  374.     Thus an auto-forwarder can be considered a non-dedicated
  375.     forwarder. Upon receiving an input message, an auto-
  376.     forwarder will submit an output message to a locally
  377.     defined (list of) address(es), which is managed by the
  378.     owner of the UA.
  379.  
  380.  
  381.  4. Requirements
  382.  
  383.     
  384.     MBSs shall follow the requirements defined in X.411 and
  385.     X.420 as a minimum. This document describes additional
  386.     requirements in terms of P1, P3, and P2. Depending on the
  387.     implementation of the MBS, it can discard requirements
  388.     that are not applicable. I.e.: as far as appropriate, any
  389.     P2 MBS shall not only follow the P2 requirements, but also
  390.     all P3 requirements, and any P3 MBS shall also follow all
  391.     P1 requirements.
  392.  
  393.  
  394.     
  395.  
  396.  
  397.  
  398.  
  399. Houttuin, Cargille     Expires: April 1993                [page  6]
  400.  
  401. INTERNET-DRAFT                                       September 1992
  402.  
  403.  
  404.  
  405.  4.1. General
  406.  
  407.       
  408.       - The following attributes shall have the same value in
  409.         the output message as in the input message:
  410.              
  411.              P2.Sensitivity
  412.       
  413.       - I case of an MBS Submit Permission violation, a
  414.         P1.DeliveryReportMPDU shall be sent to the
  415.         P1.originator of the input message. The
  416.         P1.DeliveryReportMPDU shall have the following
  417.         values:
  418.              
  419.          ReasonCode:               unableToTransfer(1)
  420.              
  421.          DiagnosticCode:           uaUnavailable(4)
  422.              
  423.          SupplementaryInformation: "Submit Permission Violation"
  424.       
  425.       - The address of the MBS administrator shall be the
  426.         same as that of the MBS, except for the Personal
  427.         Name.
  428.       
  429.       - The following types of input messages are invalid as
  430.         input messages:
  431.              
  432.              P1.ServiceMPDU
  433.              
  434.              P2.SR-UAPDU
  435.       
  436.         Instead of generating an output message, the MBS
  437.         shall send a warning message to the MBS
  438.         administrator.
  439.  
  440.  
  441.  4.2. Repliers
  442.  
  443.       
  444.       - The following attributes shall have the same value in
  445.         the output message as in the input message:
  446.              
  447.              P3.Priority
  448.              
  449.              P2.Importance
  450.       
  451.       - The following attributes shall not be used in the
  452.         output message:
  453.              
  454.              P2.replyRequest
  455.              
  456.                 
  457.  
  458. Houttuin, Cargille     Expires: April 1993                [page  7]
  459.  
  460. INTERNET-DRAFT                                       September 1992
  461.  
  462.  
  463.              P2.replyBy
  464.  
  465.              P2.expiryDate.
  466.       
  467.       - If a P2.replyToUsers field is used in the output
  468.         message, it shall not contain the address of the MBS.
  469.       
  470.       - Repliers shall not send output messages to addresses
  471.         which are likely to be MBSs, such as addresses with
  472.         the following values in the Surname attribute:
  473.              
  474.              echo
  475.              
  476.              autoanswer
  477.              
  478.              listserv
  479.              
  480.              netserv
  481.       
  482.         These values must be matched in any combination of
  483.         upper case and lower case. Instead, a replier shall
  484.         forward the input message to the MBS administrator.
  485.         The list of dangerous Surnames is subject to change;
  486.         an up-to-date version of this list is available in
  487.         [dontreply]
  488.       
  489.       - Every PerRececipientFlag in the output message shall
  490.         have the following bits set:
  491.              
  492.              Report Request:      00
  493.              
  494.              User Report Request: 00
  495.       
  496.         i.e. the Non-delivery Notification service shall be
  497.         prevented.
  498.  
  499.  
  500.  4.2.1. Echo-servers
  501.  
  502.       
  503.       - The following attributes shall have the same value in
  504.         the output message as in the input message:
  505.              
  506.              P1.ContentType
  507.       
  508.       - If a P2.replyToUsers field is present in the input
  509.         message, the output message shall be sent to this
  510.         address. Otherwise the output message shall be sent
  511.         to the originator of the input message. If the
  512.         P2.replyToUsers field contains more than one address,
  513.             
  514.  
  515.  
  516.  
  517. Houttuin, Cargille     Expires: April 1993                [page  8]
  518.  
  519. INTERNET-DRAFT                                       September 1992
  520.  
  521.  
  522.         at least the first address shall be replied to.
  523.         Replying to the others is not recommended.
  524.       
  525.       - If an output message is not sent to the P2.originator
  526.         of the input message, its P2.authorizingUsers field
  527.         shall contain the addresses of the P2.originator and
  528.         the P2.authorizingUsers of the input message.
  529.       
  530.       - The P2.originator of the output message shall contain
  531.         the address of the MBS administrator.
  532.       
  533.       - Echo servers shall not send an output message if the
  534.         input message contains a P2.In-Reply-To or
  535.         P2.crossReferences field. Instead, the input message
  536.         is forwarded to the MBS administrator.
  537.  
  538.  
  539.  4.2.2. (NON)-Delivery Messages
  540.  
  541.       
  542.       - The P1.recipient and the P2.recipient of a (non-)DM
  543.         should equal the P1.originator of the input message.
  544.       
  545.       - A message addressed to S=nosuchuser should always
  546.         result in an NRN or a non-DM being generated.
  547.       
  548.       - The P2.Originator of the output message shall contain
  549.         the address of the MBS administrator.
  550.  
  551.  
  552.  4.2.3. Command servers
  553.  
  554.       
  555.       - If a P2.replyToUsers field is present in the input
  556.         message, the output message shall be sent to this
  557.         address. Otherwise the output message shall be sent
  558.         to the originator of the input message. If the
  559.         P2.replyToUsers field contains more than one address,
  560.         at least the first address shall be replied to.
  561.         Replying to the others is not recommended.
  562.       
  563.       - If an output message is not sent to the P2.originator
  564.         of the input message, its P2.authorizingUsers field
  565.         shall contain the addresses of the P2.originator and
  566.         the P2.authorizingUsers of the input message.
  567.       
  568.       - The P2.Originator of the output message shall contain
  569.         the address of the MBS administrator.
  570.       
  571.       - Command servers shall not send an output message if
  572.         the input message contains an P2.inReplyTo or
  573.         P2.crossReferences field. Instead, the input message
  574.     
  575.  
  576. Houttuin, Cargille     Expires: April 1993                [page  9]
  577.  
  578. INTERNET-DRAFT                                       September 1992
  579.  
  580.  
  581.         is forwarded to the MBS administrator.
  582.  
  583.  4.3. Forwarders
  584.  
  585.       
  586.       - The following attributes shall have the same value in
  587.         the output message as in the input message:
  588.              
  589.              P3.ContentType
  590.  
  591.  
  592.  4.3.1. Distribution Lists
  593.  
  594.       
  595.       - The P1.contents of an output message shall be the
  596.         same as that of the input message.
  597.       
  598.       - The P1.originator of the output message shall contain
  599.         the address of the DL administrator.
  600.       
  601.       - All P1.ExtensionIdentifiers in an output message
  602.         shall be distinct.
  603.  
  604.  
  605.  4.3.2. Auto-forwarders
  606.  
  607.       
  608.       - The output message(s) shall have the P2.autoForwarded
  609.         flag set to true.
  610.  
  611.  
  612.  5. Recommendations
  613.  
  614.     
  615.     Please note that all recommendations for names of MBSs and
  616.     MBS administrators should apply to internationally used
  617.     MBSs. Local MBSs can use similar mechanisms in their local
  618.     language.
  619.  
  620.  
  621.  5.1. Generals
  622.  
  623.       
  624.       - For all MBSs, at least an MBS administrator with
  625.         Surname=postmaster should exist.
  626.       
  627.       - MBS Submit Permission implementation should be
  628.         'implicit'.
  629.  
  630.  
  631.          
  632.  
  633.  
  634.  
  635. Houttuin, Cargille     Expires: April 1993                [page 10]
  636.  
  637. INTERNET-DRAFT                                       September 1992
  638.  
  639.  
  640.  5.2. Repliers
  641.  
  642.       
  643.       - The P2.In-Reply-To attribute of an output message
  644.         should contain the IPMessageID of the input message.
  645.  
  646.       - A replier should not reply to an auto-forwarded input
  647.         message.
  648.       
  649.       - Dedicated repliers should at least log the
  650.         P2.Originator of the input message and the
  651.         P2.recipient of the output message so that the MBS
  652.         administrator can track down malicious behaviour.
  653.       
  654.       - The P2.inReplyTo and P2.crossReferences attributes
  655.         are optional in an output message. If used, they
  656.         should contain the IPMessageID of the input message.
  657.  
  658.  
  659.  5.2.1. Echo-servers
  660.  
  661.       
  662.       - The Surname  attribute of the echo server should have
  663.         the value "echo".
  664.       
  665.       - The Surname  attribute of the echo server
  666.         administrator should have the value "echo-reply".
  667.       
  668.       - The complete input message should be included in the
  669.         output message in a readable format, e.g. in an
  670.         IA5Text bodypart.
  671.       
  672.       - The P2.subject of the output message should contain
  673.         the string 'Re: ', concatenated with the subject of
  674.         the input message.
  675.       
  676.       - An echo server may put additional information in
  677.         separate bodyparts.
  678.  
  679.  
  680.  5.2.2. Command servers
  681.  
  682.     
  683.     Although it is beyond the scope of this document to define
  684.     requirements for the command syntax used by command
  685.     servers, it is in general recommended that:
  686.       
  687.       - Commands should only be put in the body of the input
  688.         message, e.g. a command server should ignore the
  689.         P2.subject field.
  690.       
  691.       - It is recommended that the recipient of the output
  692.  
  693.  
  694. Houttuin, Cargille     Expires: April 1993                [page 11]
  695.  
  696. INTERNET-DRAFT                                       September 1992
  697.  
  698.  
  699.         message can be uniquely identified from the heading
  700.         of the input message. I.e. Alternate recipients
  701.         should not be negotiated in the body of the input
  702.         message.
  703.  
  704.  
  705. 5.3. Forwarders
  706.  
  707.  
  708.  
  709.  5.3.1. Distribution Lists
  710.  
  711.       
  712.       - DLs should preferably be implemented as P1 MBSs. This
  713.         has some important advantages over P3/P2 based
  714.         implementations:
  715.              
  716.              - Using P3 would result in loosing
  717.                P1.TraceInformation
  718.              
  719.              - Better alignment with X.400(88), which also
  720.                defines DLs within the MTS
  721.              
  722.              - An MTS DL distributes P1.UMPDUContent
  723.                transparently, and will thus implicitly
  724.                implement one of the requirements for DLs.
  725.       
  726.       - The Surname attribute of the DL administrator should
  727.         be that of the DL, concatenated with "-request".
  728.  
  729.  
  730.  5.3.2. Auto-forwarders
  731.  
  732.       
  733.       - The input message should be encoded as a
  734.         P2.ForwardedIPMessage bodypart in the output message.
  735.  
  736.  
  737.  6. Mapping to X.400(88) and RFC 822
  738.  
  739.     
  740.     For the exact mapping between X.400 and RFC 822, see RFC
  741.     1327. The following table gives some examples:
  742.     
  743.     X.400(84)       X.400(88)                      RFC 822
  744.     ----------------------------------------------------------
  745.     P2.expiryDate   IPMS.Heading.expiry-time       Expiry-Date:
  746.     P2.inReplyTo    IPMS.Heading.replied-to-IPM    In-Reply-To:
  747.     P2.replyBy      IPMS.Heading.reply-time        Reply-By:
  748.     P2.replyToUsers IPMS.Heading.reply-recipients  Reply-To:
  749.     etc.
  750.     
  751.  
  752.  
  753. Houttuin, Cargille     Expires: April 1993                [page 12]
  754.  
  755. INTERNET-DRAFT                                       September 1992
  756.  
  757.  
  758.     88 based DLs shall, in case of conflicts between the
  759.     requirements stated in this document and those in
  760.     X.400(88), follow the requirements in X.400(88).
  761.  
  762.  
  763.  7. Acknowledgements
  764.  
  765.     
  766.     Within the context of the connectivity testing tool
  767.     'concord', initial work on the requirements for echo
  768.     servers and distribution lists was done within COSINE MHS
  769.     and XNREN (see [Concordreqs]).
  770.     
  771.     Thanks for comments and corrections: Urs Eppenberger
  772.     (SWITCH), Juan Pizzorno (DFN).
  773.  
  774.  
  775.  8. References
  776.  
  777.     
  778.     CCITT/ISO88a.
  779.       CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1,"
  780.       Message Handling: System and Service Overview , December
  781.       8.1.
  782.  
  783.     CCITT/ISO88b.
  784.       CCITT/ISO, "CCITT Recommendations X.420/ ISO IS 10021-7,"
  785.       Message Handling Systems: Interpersonal Messaging System,
  786.       December 1988.
  787.  
  788.     CCITT/ISO88c.
  789.       CCITT/ISO, "CCITT Recommendations X.411/ ISO IS 10021-4,"
  790.       Message Handling Systems: Message Transfer System: Abstract
  791.       Service Definition and Procedures, December 1988.
  792.  
  793.     CCITT/ISO88d.
  794.       CCITT/ISO, "Specification of Abstract Syntax Notation One
  795.       (ASN.1)," CCITT Recommendation X.208 / ISO IS 8824, December
  796.       8.2.
  797.  
  798.     Concordreqs.
  799.       COSINE MHS server
  800.       Mail: cosine-mhs-server@nic.switch.ch
  801.       FTP: nic.switch.ch, Username: cosine
  802.       File: procedures/echo-server-reqs
  803.  
  804.     Crocker82.
  805.       Crocker, D., "Standard of the Format of ARPA Internet Text
  806.       Messages," RFC 822, UDEL, August 1982.
  807.  
  808.     
  809.  
  810.  
  811.  
  812. Houttuin, Cargille     Expires: April 1993                [page 13]
  813.  
  814. INTERNET-DRAFT                                       September 1992
  815.  
  816.  
  817.     Dontreply.
  818.       COSINE MHS server
  819.       Mail: cosine-mhs-server@nic.switch.ch
  820.       FTP: nic.switch.ch, Username: cosine
  821.       File: procedures/dontreply
  822.  
  823.     Hardcastle-Kille92a.
  824.       Hardcastle-Kille, S., "Mapping between X.400(1988) /
  825.       ISO 10021 and RFC 822," RFC 1327, UCL, May 1992.
  826.  
  827.     Hardcastle-Kille92b.
  828.       Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading," RFC
  829.       8.3. UCL, May 1992.
  830.  
  831.     Kille-86.
  832.       Kille, S., "Mapping between X.400 and RFC 822," RFC 987,
  833.       June 1986.
  834.  
  835.     Westine/Postel91.
  836.       Westine, A. & Postel, J., "Problems with the Maintenance
  837.       of Large Mailing Lists," RFC 1211, March 1991.
  838.  
  839.  
  840.  9. Authors' Addresses
  841.  
  842.      
  843.     Jeroen Houttuin                                Allan Cargille
  844.     
  845.     TOP LEVEL EC                University of Wisconsin - Madison
  846.     Esserweg 14                           1210 West Dayton Street
  847.     NL-9722 SN Groningen                       Madison, WI  53706
  848.     Europe                                                    USA
  849.     Tel. +31 50 255445                       Tel. +1 608 262 5084
  850.     houttuin@amiga.physik.unizh.ch           cargille@cs.wisc.edu
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871. Houttuin, Cargille     Expires: April 1993                [page 14]
  872.  
  873.